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ABSTRACT 

Providing  long-distance  non-line-of-sight  control  for  unmanned  ground  robots  has  long  been  recognized  as  a  problem, 
considering  the  nature  of  the  required  high-bandwidth  radio  links.  In  the  early  2000s,  the  DARPA  Mobile  Autonomous 
Robot  Software  (MARS)  program  funded  the  Space  and  Naval  Warfare  Systems  Center  (SSC)  Pacific  to  demonstrate  a 
capability  for  autonomous  mobile  communication  relaying  on  a  number  of  Pioneer  laboratory  robots.  This  effort  also 
resulted  in  the  development  of  ad  hoc  networking  radios  and  software  that  were  later  leveraged  in  the  development  of  a 
more  practical  and  logistically  simpler  system,  the  Automatically  Deployed  Communication  Relays  (ADCR).  Funded  by 
the  Joint  Ground  Robotics  Enterprise  and  internally  by  SSC  Pacific,  several  generations  of  ADCR  systems  introduced 
increasingly  more  capable  hardware  and  software  for  automatic  maintenance  of  communication  links  through 
deployment  of  static  relay  nodes  from  mobile  robots.  This  capability  was  finally  tapped  in  2010  to  fulfill  an  urgent  need 
from  theater.  243  kits  of  ruggedized,  robot-deployable  communication  relays  were  produced  and  sent  to  Afghanistan  to 
extend  the  range  of  EOD  and  tactical  ground  robots  in  2012.  This  paper  provides  a  summary  of  the  evolution  of  the 
radio  relay  technology  at  SSC  Pacific,  and  then  focuses  on  the  latest  two  stages,  the  Manually-Deployed  Communication 
Relays  and  the  latest  effort  to  automate  the  deployment  of  these  ruggedized  and  fielded  relay  nodes. 
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1.  INTRODUCTION 

Modem  unmanned  ground  vehicles  (UGVs)  use  mostly  high-bandwidth  digital  radio  links,  which  are  by  nature  high- 
frequency,  typically  around  2  GHz  or  above.  These  links  operate  roughly  on  line  of  sight,  which  presents  numerous 
problems  for  teleoperation,  especially  for  the  man-portable  class  of  UGVs.  The  low  height  of  their  antennas  means  dips 
and  rises  in  the  terrain  often  block  line  of  sight  to  the  operator  or  significantly  reduce  the  Fresnel-zone  clearance,  thus 
breaking  the  communication  link.  Operation  in  urban  environments  exacerbates  the  problem. 

Starting  in  the  early  2000s,  the  Unmanned  Systems  Group  at  the  Space  and  Naval  Warfare  Systems  Center  Pacific  has 
been  engaged  in  a  number  of  projects  to  address  this  issue.  The  Autonomous  Mobile  Communication  Relays  (AMCR) 
project  demonstrated  the  use  of  autonomous  relaying  slave  robots  whose  sole  purpose  was  to  strategically  position 
themselves  to  maintain  the  communication  link  between  a  controller  and  a  lead  robot.  This  effort  was  followed  by  a 
number  of  projects  that  increasingly  moved  toward  logistically  simpler  but  more  mgged  solutions  with  the  ultimate  aim 
of  fielding  a  solution  to  the  Warfighter,  which  was  finally  achieved  in  2012. 

This  paper  provides  a  history  of  these  projects,  with  focus  on  the  most  recent  developments  and  the  lessons  learned. 


2.  AUTONOMOUS  MOBILE  COMMUNICATION  RELAYS  (AMCR) 

Funded  by  the  Defense  Advanced  Research  Projects  Agency  (DARPA)  under  the  Mobile  Autonomous  Robot  Software 
(MARS)  program  in  fiscal  years  (FYs)  2001-04,  AMCR  demonstrated  communication  relaying  by  autonomous  slave 
robots1,2  using  wireless  ad  hoc  networking  technology  developed  by  BBN  Technologies  under  a  separate  MARS  project. 
The  slave  robots  ( Pioneer  2-DXs)  were  equipped  with  lidar  and  sonars  for  obstacle  avoidance,  and  followed  the  robots 
ahead  in  a  convoy  using  laser-retroreflective  barcodes  (see  Fig.  1).  Each  slave  robot  monitored  the  quality  of  the 
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communication  link  to  the  robot  behind  it,  and  stopped  to  become  a  stationary  relay  node  when  a  link-breakage- 
prediction  algorithm  determined  that  the  link  was  about  to  fail.  An  iRobot  ATRV  and  a  Segway  RMP  were  used 
alternately  as  the  remotely-controlled  lead  robot. 


Figure  1 .  An  AMCR  demonstration,  with  the  robots  about  to  enter  an  underground  World  War  II  gun  battery  (left), 
and  the  locations  where  the  slave  robots  stopped  to  become  stationary  relay  nodes  (right). 

SSC  Pacific  developed  an  ad  hoc  networking  radio  under  this  project  that  combined  an  in-house  developed  radio 
interface  board,  an  onboard  computer,  an  802.11b  PCMCIA  radio  card,  and  BBN  Technologies’  Hazy-Sighted  Link- 
State  ad  hoc  networking  software.  Named  the  Compact  Ad  Hoc  Networking  Radio  (CANR),  100  of  these  radios  were 
produced  and  distributed  to  other  MARS  performers  for  use  on  their  autonomous  robot  projects. 


3.  AUTOMATICALLY-DEPLOYED  COMMUNICATION  RELAYS  (ADCR) 

Using  the  ad  hoc  networking  radio  technology  developed  under  AMCR ,  SSC  Pacific  started  the  ADCR  project  with  the 
goal  of  producing  a  system  that  was  more  practical.  Funded  by  the  Office  of  the  Secretary  of  Defense’  Joint  Robotics 
Program  (now  Joint  Ground  Robotics  Enterprise — JGRE)  during  FY05-06,  ADCR  produced  a  plug-and-play  radio 
repeater  system  for  the  iRobot  PackBot  family  of  robots.3  The  system  included  a  robot-mounted  Deploy er  Module  that 
would  deploy  relay  nodes  as  needed.  The  Deployer  Module  monitored  the  signal  strength  to  the  closest  deployed  relay 
node  along  the  network  route  leading  back  to  the  operator  control  unit  (OCU).  Using  the  same  predictive  filter  that 
commanded  the  AMCR  mobile  relays  to  stop,  the  Deployer  Module  would  instead  eject  a  relay  node  whenever  the  link 
was  about  to  break. 

Each  first-generation  Deployer  Module  took  two  slots  in  the  PackBot  payload  bay  and  housed  six  relay  nodes.  To 
prevent  interference  between  nearby  relay  nodes,  only  one  node  was  active  at  any  time  while  still  inside  the  Deployer 
Module.  The  Deployer  Module  made  sure  that  the  node  had  joined  the  network  before  ejecting  it  and  activating  the  next 
node,  getting  ready  for  the  next  deployment  event.  The  relay  nodes  (called  “bricks”  colloquially)  were  self-righting. 
After  ejection,  a  microcontroller  in  the  relay  node  waited  a  few  seconds  (to  ensure  the  brick  came  to  rest),  and  then 
issued  a  command  for  the  doors  to  open,  thereby  flipping  the  brick  upright  (regardless  of  how  it  landed)  and  releasing  a 
folded  spring-loaded  antenna.  Figure  2  shows  the  first- generation  ADCR  Deployer  Module  on  a  PackBot  and  a  deployed 
relay  brick. 

Although  this  ADCR  design  was  licensed  to  three  manufacturers,  none  were  produced  commercially. 


Figure  2.  A  first-generation  ADCR  Deploy er  Module  on  a  PackBot  and  a  deployed  relay  node. 


4.  SECOND-GENERATION  ADCR 

One  deficiency  of  the  first-generation  ADCR  was  the  limited  bandwidth  offered  by  the  onboard  802.11b  radios.  The 
effort  to  develop  the  second-generation  systems,  conducted  during  FY07-08  and  also  supported  by  the  JGRE,  produced 
an  improved  prototype  system.  The  Deployer  Module  was  smaller,  taking  only  one-third  of  the  PackBot  payload  bay. 
This  was  made  possible  by  the  much  thinner  relay  nodes,  which  also  made  self-righting  unnecessary.  Instead,  an 
accelerometer  in  the  relay  node  detected  which  of  the  two  faces  the  brick  had  landed  on.  A  microcontroller  then  raised 
the  dual-diversity  antennas  appropriately.  Unlike  the  first-generation,  this  new  antenna  design  could  ensure  that  the 
deployed  antennas  were  always  vertical  regardless  of  the  ground  slope  (assuming  that  the  robot  was  going  up  or  down  a 
hill  and  not  sideways  on  its  slope  when  it  deployed  the  relay  node — the  antennas  only  had  one  degree  of  rotational 
freedom). 

For  higher  bandwidth,  the  new  radios  used  hardware  developed  by  Raj ant  (funded  separately  by  the  National  Center  for 
Defense  Robotics)  to  support  an  802.1  lg  radio  card  and  the  BBN  Technologies  ad  hoc  networking  software.  Figure  3 
shows  the  second-generation  ADCR  system. 


Figure  3.  A  second-generation  ADCR  Deployer  Module  on  a  PackBot  and  a  deployed  relay  node. 


5.  AUTOMATIC  PAYLOAD  DEPLOYMENT  SYSTEM  (APDS) 


While  demonstrating  the  ADCR  system  to  the  US  Marine  Corps  I  Marine  Expeditionary  Force  (I  MEF),  the  SSC  Pacific 
team  received  numerous  suggestions  on  other  payloads  that  could  be  delivered  by  the  ADCR  Deployer  Module.  These 
suggestions  led  to  the  development  of  APDS  in  FY09-10,4  also  funded  by  the  JGRE.  In  order  to  support  as  many 
different  types  of  payloads  as  possible,  APDS  nodes  employed  a  very  modular  design.5  This  modularity  also  extended  to 
the  Deployer  Module,  making  it  easily  adaptable  to  different  types  of  robots. 

The  APDS  Deployer  Module  could  accept  three  different  payload  sizes,  from  single  to  triple  height  (see  Figure  4).  Each 
payload  was  composed  of  a  payload  carrier  (which  contains  the  actual  payload)  and  a  snap-on  payload  adapter  that 
communicated  to  the  Deployer  Module  using  an  infrared  interface.  This  allowed  third-party  developers  to  build  their 
own  payloads,  which  only  had  to  conform  to  a  set  of  SSC  Pacific  interface  specifications.  The  infrared  communication 
allowed  the  Deployer  Module  to  detect  what  type  of  payload  it  carried  and  adjust  its  behaviors  accordingly.  For 
example,  the  Deployer  Module  would  know  that  the  next  payload  in  line  to  be  dropped  was  a  passive  payload  containing 
supplies,  and  would  skip  over  it  to  deploy  a  radio  relay  payload  if  it  sensed  an  impending  break  in  communications. 

Similarly,  the  Deployer  Module  also  had  a  snap-on  adapter  specific  to  each  type  of  robot.  Thus  each  robot  manufacturer 
could  design  a  specific  Deployer  Module  adapter  to  use  the  APDS  on  their  robots. 

The  system  also  included  a  base  station  unit  that  connected  to  the  OCU  via  an  Ethernet  cable  and  contained  a  radio 
similar  to  those  found  in  the  relay  nodes  and  the  Deployer  Module.  The  base  station  unit  had  its  own  video  screen  to 
display  status  of  the  payloads  and  to  allow  the  operator  to  manually  control  the  deployment  of  various  payloads  as 
needed.  Three  example  payloads  were  developed:  (1)  an  IR  illuminator  that  could  be  deployed  to  illuminate  locations  of 
interest  at  night,  (2)  a  leave-behind  video  sensor  that  used  the  network  to  transmit  its  video  data  back  to  the  base  station 
unit,  and  (3)  an  empty  triple-height  payload  that  could  be  used  to  carry  medical  supplies,  food,  or  ammunition  to  the 
Warfighter  at  the  front  line.  A  marsupial  robotics  capability  has  been  demonstrated  by  deploying  a  magnetic-wheel 
micro-UGV  using  the  empty  payload  carrier. 


Figure  4.  Th qAPDS,  showing  various  components. 


6.  THIRD-GENERATION  ADCR 


The  third-generation  ADCR  effort  was  a  technology  improvement  internally  funded  by  SSC  Pacific’s  Naval  Innovative 
Science  and  Engineering  (NISE)  program  during  FY 10-11.  The  radio  hardware  was  replaced  by  commercial-off-the- 
shelf  processor/router  boards  (GateWorks  GW2350 )  and  Mini  PCI  802.1  lg  radios.  However,  the  most  significant 
accomplishment  from  this  effort  was  the  switch  to  internally-developed  ad  hoc  networking  software  targeting 
teleoperation. 

Teleoperation  of  mobile  robots  requires  unique  network  characteristics  that  are  different  from  those  for  static  nodes  or 
autonomous  robots,  to  include:  minimal  or  no  link-breakage,  fast  convergence  to  a  new  route  after  a  link  failure,  and  a 
higher  throughput  with  low  latency  across  multiple  nodes  to  accommodate  several  video  streams.  We  conducted 
comparisons  of  several  open-source  ad  hoc  networking  architectures,  picked  the  most  promising  architecture  ( Babel ), 
and  optimized  it  for  the  above  requirements.6  We  also  started  work  on  a  new  link-quality  estimation  technique. 
However,  this  work  was  interrupted  by  emergent  in-theater  requirements  (which  started  the  Manually  Deployed 
Communication  Relays  project  below),  and  was  finished  later  under  the  fourth- generation  ADCR  effort. 


7.  MANUALLY-DEPLOYED  COMMUNICATION  RELAYS  (MDCR) 

In  late  FY10  we  received  a  request  from  the  Naval  Explosive  Ordnance  Disposal  Technology  Division 
(NAVEODTECHDIV),  responding  to  two  Joint  Urgent  Operational  Need  Statements  from  US  Central  Command,  to 
provide  a  relay  system  for  evaluation  at  the  Joint  Counter-IED  Facility  at  the  Naval  Air  Warfare  Center  in  China  Lake, 
CA.  We  provided  two  repackaged  relay  nodes  (the  automatic  deployment  capability  was  not  required),  which  were 
tested  along  with  several  other  solutions  from  other  laboratories  and  commercial  vendors.  Our  system  was  picked  for 
further  development.  Subsequently,  with  funding  from  the  Navy  Expeditionary  Combat  Branch  (OPNAV  N857)  and 
managed  by  NAVEODTECHDIV,  we  designed  and  built  15  prototype  MDCR  kits  for  operational  assessment  at  Fort 
Leonard  Wood,  MO,  and  in  Afghanistan.  Five  kits  each  were  built  for  the  iRobot  500  PackBot ,  510  PackBot/FasTac , 
and  310  SUGV/MiniEOD .  (A  prototype  system  was  also  developed  for  the  QinetiQ  Talon  robot  as  part  of  the  initial 
evaluation  but  was  not  selected  for  further  development.  This  Talon  system  used  the  same  relay  nodes  as  the  PackBot 
systems,  and  all  robots  and  their  relays  would  operate  in  the  same  mesh  network.) 

After  the  prototype  systems  passed  the  operational  assessments,  we  were  tasked  to  develop  a  level-III  (production) 
technical  data  package  (TDP)  and  two  end-of-line  test  fixtures  for  semi-automated  functional  verification  of  production 
units  as  they  exit  production  lines.  Using  this  TDP,  the  Robotic  Systems  Joint  Project  Office  fielded  243  kits  in 
Afghanistan  in  the  second  half  of  2012,  built  by  the  Tobyhanna  Army  Depot. 

Each  MDCR  kit  includes  two  ruggedized  relay  nodes,  to  be  carried  and  deployed  using  deployment  forks  attached  to  the 
flippers  of  the  robots,  end-point  radios  for  the  robots  and  OCUs,  and  miscellaneous  hardware  and  manuals  (see  Figure 
5).  The  MDCR  relay  nodes  are  waterproof  and  use  standard  military  BB-2557  rechargeable  batteries.  The  radios  used  are 
compatible  with  coalition  Counter-Remotely-controlled-IED  Electronic  Warfare  (CREW)  jammers.  The  antennas  are 
flexible  and  foldable.  (Earlier  prototype  antennas  were  not  foldable  and  proved  to  be  a  weak  point  in  the  system.)  Each 
deployment  fork  was  designed  to  connect  to  and  disconnect  from  the  robot  flipper  with  the  use  of  a  quick-release  pin. 
An  angular  attachment  offset  between  the  forks  allows  the  relay  nodes  to  be  deployed  and  picked  up  one  at  a  time  (see 
the  left  image  in  Figure  5). 

Each  relay  node  has  an  LED  indicator  that  tells  the  operator  through  its  solid  or  blinking  status  whether  the  unit  is 
offline,  in  the  mesh  network,  or  is  trying  to  join  the  network.  The  Babel- based  ad  hoc  networking  software  developed 
and  optimized  for  teleoperation  during  the  third-generation  ADCR  effort  was  used  without  the  automatic  deployment 
function.  The  entire  system  was  designed  to  be  plug-and-play  on  each  type  of  robot  it  was  built  for — no  modification  of 
the  robot  or  controller  software  was  required. 


Figure  5.  MDCR  relays  carried  by  an  iRobot  510  FasTac  (left)  and  an  MDCR  kit  (right). 


8.  FOURTH-GENERATION  ADCR 

With  the  completion  of  MDCR ,  we  returned  our  focus  to  ADCR ,  but  this  time  with  the  goal  of  providing  more  autonomy 
for  the  fielded  MDCR  systems.  With  FY12  internal  NISE  funding,  we  demonstrated  a  new  system  that  could  deploy  the 
MDCR  relay  nodes  either  automatically  or  semi-automatically.  Motorized  deployment  forks  were  designed  that  were 
mounted  on  the  rear  of  the  robot  (an  iRobot  51 0  PackBot  was  used  as  the  test  platform — see  Figure  6).  A  dongle  was 
designed  for  the  OCU  to  provide  buttons  for  switching  between  automatic  and  semi-automatic  deployment  modes  and 
for  controlling  the  deployment  of  individual  relay  nodes.  (The  addition  of  the  dongle  ensured  that  the  system  remained 
plug-and-playable,  with  no  modification  to  robot  or  OCU  software.)  The  link-quality  estimator  that  began  under  the 
third-generation  ADCR  project  was  completed.  The  estimator  provides  a  “weak  link”  warning  based  on  received  signal 
strength  indicator  (RSSI)  data  and  an  “imminent  failure”  alert  based  on  trends  in  the  video  data  throughput.  Through 
extensive  testing,  we  noted  that  the  video  data  throughput  remained  fairly  constant  long  after  that  RSSI  value  had 
decreased.  Then  at  the  point  where  video  glitches  were  beginning  to  appear,  the  averaged  video  data  throughput 
dropped  fairly  linearly  while  its  variance  increased  significantly.  We  designed  two  linear  classifiers  to  detect  this 
condition,  one  based  on  the  throughput  variance,  the  other  on  the  averaged  throughput  trend.  Supervised  learning 
algorithms  were  used  to  train  these  classifiers.  An  “imminent  failure”  alert  is  issued  when  both  classifiers  detect  the 
condition  for  three  consecutive  time  samples.7 


Figure  6.  The  fourth-generation  ADCR  system  on  an  iRobot  510  PackBot.  The  left  node  is  being  deployed. 


For  this  design,  the  OCU  end-point  radio  performed  the  link  monitoring  function  instead  of  the  Deploy er  Module  as  in 
previous  generations.  This  was  necessary  in  order  to  monitor  the  throughput  of  the  received  UDP  video  data.  In  the 
automatic  mode,  the  imminent- failure  alert  triggers  the  automatic  deployment  of  a  relay.  In  the  semi-autonomous  mode, 
a  link-quality  indicator  LED  on  the  dongle  turns  from  green  to  yellow  to  give  the  weak-link  warning  and  inform  the 
operator  to  start  looking  for  a  good  location  to  deploy  a  relay  node.  This  LED  turns  red  to  indicate  the  imminent- failure 
condition,  alerting  the  operator  to  deploy  the  relay  immediately.  We  believe  that  this  mode  would  be  favored  by  the  user 
in  the  field.  It  allows  the  user  to  control  exactly  where  a  relay  node  is  placed.  This  location  can  depend  on  a  number  of 
factors  unknown  to  the  system,  for  example:  the  overall  mission,  upcoming  maneuvers,  the  terrain  ahead,  visibility  and 
ease  of  locating  the  relay  node  for  later  retrieval,  etc. 


9.  LESSONS  LEARNED 

In  this  section  we  will  discuss  some  lessons  learned  as  well  as  notes  on  deficiencies  we  saw  in  the  design  of  other  relay 
systems  that  we  have  seen  in  field  tests.  These  should  be  kept  in  mind  when  designing  a  radio  relay  system. 

One  of  the  common  weaknesses  we  have  seen  in  other  relay  systems,  which  caused  them  to  fail  in  field  tests,  is  the  use 
of  high-gain  antennas.  While  high-gain  antennas  may  seem  desirable  for  range  extension,  this  gain  typically  is  achieved 
by  focusing  the  radiation  pattern.  In  the  case  of  an  omnidirectional  antenna,  the  radiation  pattern  “donut”  is  flattened. 
This  causes  connectivity  problems  when  two  neighboring  nodes  are  not  at  the  same  elevation,  or  one  is  tilted  due  to 
uneven  terrain. 

Another  factor  to  take  into  account  is  the  height  of  the  antenna  on  the  robot.  The  height  of  the  relay  node  antenna  (when 
placed  on  the  ground)  must  be  equal  to  or  greater  than  this  height.  Otherwise,  since  the  robot  or  Deployer  Module  would 
only  drop  a  relay  node  when  its  received  signal  strength  has  degraded,  the  deployed  relay  node  with  a  lower  antenna 
would  encounter  an  even  lower  link  quality  and  might  not  be  able  to  join  the  network  at  all. 

Also,  RSSI  does  not  correspond  well  with  link  quality.  We  have  observed  that  throughput  data  often  remains  constant 
well  after  RSSI  has  started  to  decrease.  Monitoring  the  throughput  itself  is  a  more  effective  method  for  determining 
when  to  deploy  a  relay  node.7 

The  high  throughput  required  to  transfer  multiple  streams  of  video  data  from  a  remotely  controlled  vehicle  (often 
outfitted  with  multiple  cameras)  limits  the  practical  number  of  relay  nodes.  For  our  systems,  we  have  noticed  that 
problems  controlling  the  vehicle  begin  to  appear  after  three  relays  are  in  the  route.  This  can  be  mitigated  by  reducing 
video  resolution  and/or  dropping  color  information  from  the  video  streams.  Another  solution  is  to  use  dual-frequency 
radios  to  allow  simultaneous  transmission  and  reception  of  data  at  each  node,  increasing  the  overall  throughput  of  the 
mesh  network. 

“Route  flapping”  is  a  potential  problem  when  the  routing  algorithm  switches  between  two  routes  of  nearly  equal  “cost” 
(which  could  be  a  function  of  link  quality,  number  of  intermediate  nodes,  etc.).  The  constant  switching  between  two 
routes  could  bring  the  network  to  a  halt.  One  way  to  prevent  this  is  to  use  some  measure  of  hysteresis  and  “good 
enough”  metrics  so  that  a  new  route  is  not  selected  as  long  as  the  current  route  is  still  good  enough  to  carry  the  required 
network  traffic.6 

When  several  nodes  are  in  close  proximity,  they  also  tend  to  jam  each  other  so  that  none  can  enter  the  network.  In  the 
first-  and  second-generation  ADCR  systems  only  one  stowed  node  inside  the  Deployer  Module  was  active  at  any  given 
time.  The  system  ensured  that  the  active  node  had  successfully  joined  the  network  before  deploying  it  and  activating  the 
next  node.  In  the  MDCR  and  fourth-generation  ADCR  designs,  both  relay  nodes  were  active  while  being  carried  by  the 
robot.  However,  the  angular  offset  between  the  two  antennas  allowed  both  to  be  in  the  network.  We  have  observed  that 
placing  the  two  nodes  on  a  level  table  top  at  the  same  separation  distance  caused  them  to  block  each  other  from  entering 
the  network. 


10.  CONCLUSIONS 


Our  experience  with  these  projects  has  shown  that  the  path  from  research-and-development  to  fielding  is  not  always  a 
straight  line.  Our  first  project,  AMCR ,  demonstrated  the  most  advanced  machine  intelligence  and  autonomy.  However, 
to  bring  the  technology  to  the  Warfighter,  other  real-world  concerns  came  into  play,  including  logistics,  ruggedness, 
operational  simplicity,  and  user  acceptance.  ADCR  was  much  simpler,  with  only  a  portion  of  the  autonomy  retained  but 
more  logistically  realistic.  The  design  that  was  finally  fielded,  MDCR ,  had  no  autonomy  except  for  network  route 
selection.  The  fourth-generation  ADCR  attempted  to  reinsert  autonomy  into  the  fielded  systems.  We  believe  that  its 
semi-automatic  deployment  mode  is  likely  the  best  solution  that  will  be  acceptable  to  the  user.  It  combines  user  input 
(which  makes  use  of  human  perception  and  decision-making  abilities)  with  the  radio’s  link-quality  monitoring  capability 
and  allows  for  safe  operation  in  the  widest  variety  of  terrain. 
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